EMSUSD-490 Fixes outerliner not refreshing when performing a UsdUndoVisibleCommand #3345
Conversation
|
It seems that when: 1- Making a prim invisible the following notifications are sent: 2- When setting the visibility back to "Inherited" / "Visible", only the following is sent which makes sense as the attribute already exists: 3- When Undoing after manually making an item invisible, only the following notification is sent as the attribute will now be inheriting data: This is checked here: maya-usd/lib/usdUfe/ufe/StagesSubject.cpp Lines 142 to 167 in ce7fc17 The bug is for #3. @seando-adsk Should we move the fix inside the AttributeChangeType::ValueRemoved ? |
lib/usdUfe/ufe/StagesSubject.cpp
Outdated
| // Special case when Undoing a visibility change, the notice.GetChangedInfoOnlyPaths() | ||
| // does not contain the change, hence handling visibility notification in re-synch path. | ||
| if (changedPath.GetNameToken() == UsdGeomTokens->visibility) { | ||
| Ufe::VisibilityChanged vis(ufePath); | ||
| notifyWithoutExceptions<Ufe::Object3d>(vis); | ||
| } |
There was a problem hiding this comment.
I'm not sure the order matters, but I wonder if sending this extra visibilityChanged should come after the processAttributeChanges() just below. This would then match the order in the ChangedInfoOnlyPaths() loop.
There was a problem hiding this comment.
@seando-adsk I actually had to move it as per this finding since having it in at line 398 caused duplicate notifications to be sent which failed the visibility test.
…t to avoid sending duplicate notifications
AramAzhari-adsk
added
adsk
|
One test on one platform did not pass which is a known random occurrence: |
seando-adsk
deleted the
azharia/EMSUSD-490/fixes-outerliner-not-refreshing-when-performing-a-UsdUndoVisibleCommand
branch
When undoing a visibility command, UsdNotice::ObjectsChanged does not produce a path for Info Change but still generates a path for Re-sync Change which has the Visibility token. The special case is added to refresh when in the latter path.